chore(manifest): add security_group to env manifest#3749
chore(manifest): add security_group to env manifest#3749mergify[bot] merged 14 commits intoaws:mainlinefrom
Conversation
bvtujo
left a comment
There was a problem hiding this comment.
couple of dumb questions but this looks great!
|
🚀 |
| } | ||
| egress = strings.TrimSpace(string(out)) | ||
| } | ||
| return &template.SecurityGroupConfig{ |
There was a problem hiding this comment.
So if the Ingress/Egress fields are empty, this will return a *template.SecurityGroupConfig object with nil values for ingress and egress?
Would it be more efficient to return earlier if IsZero, as that's the more common use case?
|
Looks good! |
huanjani
left a comment
There was a problem hiding this comment.
Just a couple small comments!
|
Is it possible to hold on to merging this PR until after the release please 🥺 If we can we'd like to halt on env template CFN changes unless it's about the env manifest. Once released, we can merge the PR! |
| {{.SecurityGroupConfig.Ingress | indent 8}} | ||
| {{- end }} | ||
| {{- if and .SecurityGroupConfig .SecurityGroupConfig.Egress }} | ||
| SecurityGroupEgress: | ||
| {{.SecurityGroupConfig.Egress | indent 8}} |
There was a problem hiding this comment.
Ideally we don't put yaml.node for them because then it wholly depends on customers to write CFN template which is very similar to what addons should do. As a manifest field, it is usually with some level of abstraction (integrated logic). For example, allow_vpc_ingress and from_cdn
|
|
||
| // SecurityGroupConfig holds the fields to import security group config | ||
| type SecurityGroupConfig struct { | ||
| Ingress string |
There was a problem hiding this comment.
So does the marshaling logic depend on the fact that customers have to specify the exact same keys in the manifest vs in CF?
For example, the manifest config
network:
vpc:
security_group:
ingress:
- IpProtocol: tcp
FromPort: 0
ToPort: 65535
- IpProtocol: tcp
FromPort: 1
ToPort: 6
egress:
- IpProtocol: tcp
FromPort: 0
ToPort: 65535`maps to the CloudFormation:
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 0
ToPort: 65535
- IpProtocol: tcp
FromPort: 1
ToPort: 6
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 0
ToPort: 65535but this means that the customer has to write manifest keys in two separate capitalization styles, which may be confusing. Are there any other places in the manifest that we directly use CF keys versus remapping them to their snake case counterparts (protocol, from_port, and to_port)?
|
To address everyone's concern (including @bvtujo , @iamhopaul123 ) about accepting security_group as We will target just CIDR for now which will solve some use cases such as mentioned here |
|
It looks like this doesn't pass CI, likely due to a broken merge? |
This reverts commit 5de9487.
This PR fix the issue #3719 Related to [#3749](#3749) Now customers can define security group rules for EnvironmentSecurityGroup (e.g. ingress/egress) in their env manifest Sample manifest template with security group rules is given below ``` network: vpc: security_group: ingress: - ip_protocol: tcp from_port: 80 to_port: 80 cidr: 0.0.0.0/0 egress: - ip_protocol: tcp from_port: 80 to_port: 80 cidr: 0.0.0.0/0 ```
This PR fix the issue #3719
Now customers can define security group rules for EnvironmentSecurityGroup (e.g. ingress/egress) in their env manifest
Sample manifest template with security group rules is given below
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.